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Description 



[0001] This invention relates to radio communication 
networks. 

[0002] General paclcet radio Service (GPRS) and its 
enhancement, enhanced GPRS (EGPRS), use a paclc- 
et-mode transfer technique to provide high-speed and 
low-speed data services to mobile users based on the 
current GSM systems. Coupled with the development 
of wide band code division multiple access (WCDIVIA) 
technology to provide broadband radio access, univer- 
sal mobile telecommunication system (UI^S) will pro- 
vided packet data sen/ices based on the evolution from 
GPRS systems. In GPRS/UiyflTS, applications based on 
standard data protocols are supported, and inter-work- 
Ing Is defined with Internet protocol (IP) networks and X. 
25 networks. Although several quality of sen/lce (QoS) 
profiles are defined, the notion of sen/ice differentiation 
between the strict delay/bandwidth constraint services 
and the general delay-insensitive data transfer sewices 
is not supported in cunrent GPRS specifications. This 
lack of clear sen/ice differentiation has been recognised 
to be problematic in meeting the ever-pushing need to 
use GPRS to support a wide variety of services with dif- 
ferent QoS requirements. 

[0003] One major problem in supporting QoS, and ef- 
fectively, servtee differentiation, in GPRS is that cun-ent 
GPRS specifications do not support the co-existence of 
multiple flows/services for a subscriber. One single type 
of service is designated to a mobile station (IViS) at- 
tached to the GPRS system with some pre-defined QoS 
profile. For example, a packet data protocol (PDP) con- 
text is created and associated one-to-one with an IP ad- 
dress of a MS. The PDP context defines the transmis- 
sion information for the packets belonging to the same 
application. Consequently all packets to and from the 
Wis will be treated in the same way (the GPRS QoS pro- 
file). This single-flow QoS provisioning model of GPRS 
Is very restrictive in supporting a multimedia application 
which contains multiple media components and origi- 
nates multiple flows of packets, each flow presenting dif- 
ferent packet delivery requirements In ternns of delay, 
throughput and packet loss. 

[0004] In addition to the limitation of the single-flow 
Q6S provisioning model, the media access control 
(iVIAC) protocol defined in GPRS does not provide dis- 
tinction between different flows with different QoS re- 
quirements, in particular, there is no explicit support for 
real-time flows with bounded delay requirements. More- 
over, admission control is not properly defined in GPRS. 
[0005] There have been some proposals to expand 
the single-flow QoS provisioning model of GPRS by In- 
troducing multiple PDP sub-contexts (or secondary con- 
texts) in addition to an original PDP context. Each sub- 
context has an associated QoS for a specific flow within 
a multimedia session. The packets belonging to the 
same flow whose transmission attributes are defined by 
its PDP sub-context are treated in the same way while 



the packets belonging to different flows with different 
PDP sub-contexts are treated distinctively so as to meet 
the different QoS requirements. 
[0006] Several problems have been envisaged with 
5 this fine-grain QoS support model. The number of sub- 
contexts and subsequently the number of PDP sub-con- 
text activations increase In proportion to the number of 
media components as contained in multimedia session 
for an MS. This per-fiow PDP will present a big concern 
10 in tenns of control complexity and the number of PDP 
sub-contexts that need to be maintained and dynami- 
cally managed in the GPRS support nodes (GSNs) 
which may well fonn a many-to-many Inter-connection 
networking pattem between serving GSNs (SGSNs) 
15 and gateway GSNs (GGSNs), each serving a large 
number of multimedia MSs. In addition, this fine-grain 
QoS notion may well be largely compromised at the IP 
layer and'l^C layer where only a limited set of service 
differentiation is available. Rnally it requires some sub- 
20 stantial changes over cunent GPRS flow handling 
mechanisms such as PDP sub-Context (secondary 
PDP Context) Activation/Release. This will inevitably In- 
crease the control complexity. 
[0007] The reader is directed to the following refer- 
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EN 301 344 V6.4.0 (1999-08), "Digital cellular tele- 
communications systems (Phase 2+) ; General 
Packet Radio Service (GPRS); Servkje description; 
Stage 2 (GSM 03.60 version 6.4.0 Release 1 997) 
EN 301 349 V6.4.0 (1999-07), « Digital cellular tel- 
ecommunications system (Phase 2+); General 
Packet Radio Service (GPRS); Mobile Station (MS) 
- Base Station System (BSS) Interface; Radio Link 
Control/ Medium Access Control (RLC/M AC) proto- 
col (GSM 04.60 version 6.4.0 Release 1997). 
GSM 09.60 V6.3.0 (1999-04), "Digital cellular t^ie- 
communications system (Phase 2+); General Pack- 
et Radio Sewice (GPRS); GPRS Tunnelling Proto- 
col (GTP) across the Gn and Gp Interface; (GSM 
09.60 version 6.3.0 Release 1997). 
3G TR 23.907 1.3.0 (1999-06), "3"* Generation 
Partnership Project; Technical Specification Group 
Services and System Aspects QoS Concept (3GTR 
23.907 version 1 .3.0). 

3G TS 23.121 V3.0.0 (1999-07), " S"* Generation 
Partnership Project; Technical Specification Group 
Services and Systems Aspects; Architectural Re- 
quirements for Release 1999 (3G TS 23.121 ver- 
sion 3.0.0) 



[0008] The invention Is based on the concept of serv- 
ice differentiation by a set of QoS Classes (or Service 
Classes) instead of on each micro-flow as proposed In 
55 GPRS. Moreover, to support the multimedia sen^ices 
with diverse QoS requirements, the concept of multl- 
sen^lce PDP (MPDP) and multiservice GPRS tunnelling 
procedure (MGTP) are introduced to exploit the current 
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. specifications and definitions as mucli as possi- 
wnild minimising extra changes over current GPRS 
standards. 

[0009] Against this baclcground there Is provided a ra- 
dio communication networI< in which dataflows between 
nodes In pacl<ets, In which each flow Is assigned to one 
of a plurality of types of network service access points, 
different types of network servtee access points provid- 
ing different classes of quality of service. 
[0010] Each packet in a flow preferably has a header 
containing a network service access point Indicator 
Identifying the type of network sen/Ice access point re- 
■"^ to provide a quality of servtee allocated to the 

[001 'i J A pi.raiity cf flows relating to a single mobile 
station, which flows are allocated the same or different 
quality of service classes, are preferably assigned to a 
single multi-service tunnel defined in the packet headers 
by the combination of an address of the mobile and the 
network service access point indicator. 
[0012] One embodiment of the invention will now be 
described, by way of example, with reference to the ac- 
companying drawings, in which: 

Rgure 1 is a flow diagram showing the procedure 
for activating an MPDP 

nqure J? Illustrates the fields I a modified QoS profile 
■ info r.*r. aiiori element; 
Figure 3 shows how GTP protocol data units 
(G_PDUs) are dispatched through the MGTP; 
Figure 4 shows how service is differentiated at the 
logteal link control (LLC)/l\^ AC layers for uplink traf- 
fic at the iyiS; 

Figure 5 shows how service Is differentiated for 
downlink traffic In the base station system (BSS); 
Figure 6 shows how service Is differentiated for up- 
link traffic In the BSS; and 
Rgure 7 illustrates a modified control fields fonnat. 

; ^..^'^'tMce Dffferentiation QoS Framework for 
GPRS/UMTS 

[0013] It Is proposed that the QoS provision in GPRS/ 
UMTS is based on the QoS Classes or Service Classes. 
AHmited number of QoS Classes are identified and the 
appropriate and minimum number of pararneters are se- 
lected and defined to describe each QbS Class. All cur- 
rent and future applications are expected to be fully de- 
scribed by one QoS Class or a combination of the QoS 
Classes and the network delivery behaviour for the in- 
f OHDatlon of the application is best described by the pa- 
^. -vieters of the selected QoS Classes. 
; jV' ^ As an example, the four QoS Classes (3GPP 
TR23.907) can be identified as the basic set of Service 
Classes based which simple or complicated applica- 
tions can be built up. 

* Conversational Service Class, 



* Streaming Service Class, 

* Interactive Service Class, 

* Background Sen^lce Class. 

s [0015] As a reference, the foliowing parameters are 
may best characterise the above QoS Classes. 

* Maximum Bit Rate 

* Delivery order 

10 • Maximum SDU Size 

* SDU format Information 

* Reliability 

* Transfer delay 

* Guaranteed Bit Rate 
15 ♦ Burst Size 

* Traffic handling priority 

* Allocation/Retention Priority 

[001 6] In the proposed QoS Framework, the multiple 
flows in a multimedia session are classified Into the QoS 
Classes. A flow is identified by their corresponding QoS 
Class In those network functional elements/layers 
where Service DifFerentiation is perfomned. This means 
that flows of the same QoS Class will be treated the 
same way. Service Flows of different QoS Classes will 
be processed in different ways so as to maintain the 
service attributes as rej3resented by the parameters of 
each QoS Class. 

[0017] In GPRS, Service Differentiation Is perfonmed 
at the MS^ radio access network (I^N) (enhanced RAN 
or ERAN for EGPRS), SGSN and GGSN. Sen/ice Dif- 
ferentiation operations including both signalling and da- 
ta transmission procedures in GPRS are adapted, ex- 
tended and modified where necessary. The changes on 
cunrent GPRS standard specifications should be kept to 
minimum while an effective service differentiation is 
achieved. 

[0018] As the basic building elements of the frame- 
work, MPDP Context and Multi-Service GTP adapted 
from the standard GPRS PDP Context and GTP Multi- 
Service Grouping are introduced to facilitate the 
achievement of service differentiation In GPRS net- 
works. 

[001 9] A complete description of the GPRS QoS con- 
trol procedures is not Included herein. Only those con- 
cepts and definitions that have been changed will be 
presented with associated explanations. 

Muitl-Servlce PDP Context 

[0020] A Multi-Service PDP Context (MPDP) is de- 
rived from the standard GPRS PDP Context. A FTP 
(Polnt-tb-Point) GPRS subscription contains the sub- 
scription of one or more PDP addresses. An individual 
PDP Context in the MS, the SGSN, and the GGSN de- 
scribes each PDP address. A MPDP Context is gener- 
ated for a subscription, which requests more than one 
QbS Classes. Please note that the number of flows is 
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not necessarily equal to the number of QoS Classes. A 
subscription with more than one flow of the same QoS 
Class will activate a single-service PDP Context. A sin- 
gle-service POP Context is taken as a special case of a 
MPDP Context. 

[0021] In a MPDP Context, a set of Per-Class QoS 
Profiles is defined in replace of the QoS profile in the 
standard GPRS PDP Context. The maximum number of 
Per-Class QoS Profiles In a MPDP Context is decided 
by the number of the QoS Classes that have been iden- 
tified. As an example, for a GPRS network whteh pro- 
vides the four QoS Classes above, the maximum 
number of Per-Class QoS Profiles In a MPDP Context 
is four. 

[0022] According to the Service Differentiation QoS 
Framework, the network service access point indicator 
(NSAPI) as contained In a MPDP Context is extended 
to be a set of NSAPIs, each of which corresponds to a 
specific QoS Class. Flows belonging to the same sub- 
scriber and having the same QoS Class will be multi- 
plexed over the same type of NSAPI. The number of 
types of NSAPI is nonmally equal to the number of the 
QoS Classes that a user has subscribed for and wishes 
to activate at that moment 

[0023] The MPDP Contexts maintained by MS, SGSN 
and GGSN may be different. The differences are high- 
lighted as follows. 

[0024] For the MPDP Context at the MS, two sets of 
Per-Class QoS profiles are maintained. One set Is the 
Requested Per-Class QoS Profile and the other is the 
Negotiated Per-Class QpS profile. A Requested Per- 
Class QoS profile may be degraded to a tower specifi- 
cation of the same QoS Class. 
[0025] Forthe MPDP Context at the SGSN, three sets 
of Per-Class QoS profiles are maintained. One set is the 
Subscribed Per-Class QoS Profile, the second one is 
the Requested Per-Class QoS Profile and the third set 
is the Negotiated QoS Profile. A Negotiated Per-Class 
QoS Profile is nomialiy no greater in its specifications 
than the Subscribed Per-Class QoS Profile and the Re- 
quested Per-Class QoS Profile unless the SP decides 
to do so. 

[0026] For the MPDP Context at the GGSN, only the 
set of Negotiated Per-Class QoS Profiles is niaintained. 
[0027] The Radio Priority for the MPDP Contexts at 
the MS and the SGSN Is extended to be a set of Radio 
Priorities, each of which maps to a certain QoS Class. 
The PDUs of the flows with the same QoS Class will be 
assigned the same level of Radio Priority. 
[0028] The MPDP Context Activation/Modification/ 
Deactivation procedures are similar to those of the 
standard GPRS PDP Context Activation/Modification/ 
Deactivation. 

[0029] As an example for a MPDP Context Activation 
process, a multimedia session management (SM) entity 
at the MS triggers Activate MPDP Context Request. The 
multimedia components to be included in themuttimedia 
session will be grouped and classified Into the number 



of the QoS Classes that are authorised to the subscriber. 
A change on the selected QoS Class such as addition/ 
deletion of a QoS Class Is achieved by using the MPDP 
Context Modification procedure. Addition/deletion of a 
5 media flow does not necessarily lead to the addition/de- 
letion of a QoS Class. 

[0030] The PDP Context Activation procedure is illus- 
trated in Figure 1 . Each step Is explained in thefoilov/ing 
list 

10 

1 ) The MS sends a Muiti-Sen/ice Activate PDP Con- 
text Request, a message containing NSAPI, TID, 
PDP Type, PDP Address, Access Point Name, QoS 
Requested, and PDP Configuration Options, to the 

15 SGSN. The MS uses the PDP Address to indicate 
whether it requires the use of a static PDP address 
or whether it requires the use of a dynamic PDP ad- 
dress. The MS leaves the PDP Address empty to 
request a dynamic PDP address. The MS uses the 

20 Access Point Name to select a reference point to a 
certain external networi<. The Access Point Nanrie 
(APN) is a logical name refening to an external 
packet data network that the subscriber wishes to 
connect to. QoS Requested indicates the desired 

25 QoS profile. PDP Configuration Options may be 
used to request optional RDP paranieters f rom the 
GGSN (see GSM 09.60). PDP Configuration Op- 
tions is sent transparently through the SGSN. 



3) The SGSN validates the Multi-Service Acth/ate 
PDP Context Request using PDP Type (optional), 
PDP Address (optional), and Access Point Narr(«. 
35 (optional) provided by tiie MS and the PDP context 
8ul>8cription records. 

[0031] if no GGSN address can be derived or if the 
SGSN has detemnined that the Activate PDP Context 

40 Request is not valid according to the its mles, tiien the 
SGSN rejects the PDP context activation request 
[0032] If a GGSN address can be derived, tiie SGSN 
creates a tunnel identifier (TID) forthe requested PDP 
context by combining the international mobile subscribe 

45 er identifier (IMSI) stored in the MM context with the 
NSAPI received from the MS. if the MS requests a dy- 
namic address, then the SGSN lets a GGSN ailocats 
the dynamic address. The SGSN may restrict the re- 
quested QoS attributes given Its capabilities, the current 

50 load, and the subscribed QoS profile. 

[0033] The (third generation) SGSN then sends a ra- 
dio access bearer (RAB) Service Request to the UMTS 
terrestrial radio network (UTISAN). The request contains 
tiie IMSI, NSAPI, Flow label uplink for SGSN, SGSN IP 

55 address, and QoS negotiated. The UTRAN uses the Ra- 
dio access bearer set up procedure to indicate to the 
mobile station or user equipment (UE), with RRC sig- 
nalling, the new Bearer ID established and tiie con^e- 



30 2) Security functions may be executed. 

3) The SGSN validates the Multl-Servlc 
PDP Context Request using PDP Type 
PDP Address (optional), and Access P< 
35 (optional) provided by tiie MS and the PC 
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sponding NSAPI. The UTRAN replies with the RAB 
Service Response containing the iMSI; NSAPI, Ftowia- 
bel downlink for RNC, RNC IP address, and QoS nego- 
tiated. 

[0034] Note that the NSAPI is sufficient to Indicate the 
QoS class. [However, since the position of the Flow l_a- 
bel field within the GTP tunnel header malces it easier 
to manipulate, the Flow Label field can be used to indl- 
. '0 the QoS class, I.e. there Is a one-to-one mapping 
i_» jiween NSAPI and the Flow Label value 
[0035] 4) Only if there are sufficient radio resources 
will the SGSN send a Create MPDP Context Request 
message .containing PDPType, PDP Address, Access 
Point Name, QoS Negotiated, TID, Selection Mode, and 
PDP Configuration Options, to the affected GGSN. The 
Access Point Name is the APN Network Identifier of the 
APN selected. The PDP Address is empty if a dynamic 
address Is requested. The GGSN may use Access Point 
Name to find an extemai network. Selection Mode Indi- 
cates whether a subscribed APN was selected, or 
whether a non-subscribed APN sent by MS or a non- 
3Ubscribed APN chosen by SGSN was selected. The 
GGSN may use Selection Mode when deciding whether 
to accept or reject the PDP context activation. For ex- 
ample, If an APN requires subscription, then the GGSN 
Is configured to accept only the PDP context activation 
thkt req uests a subscribed APN as indicated by the SG- 
SN with Selection Mode. The GGSN creates a hew entry 
in Its PDP coritext table and generates a Charging Iden- 
tity (Id). The new entry allows the GGSN to route PDP 
PDUs between the SGSN and the extemai PDP net- 
work, and to start charging. The GGSN may further re- 
strict QbS Negotiated given its capabilities and the cur- 
rent load. The GGSN then returns a Create PDP Con- 
Response message containing the TID, PDP Ad- 
dress, Reordering Required, PDP Configuration Op- 
tions, QoS Negotiated, Charging Id, and Cause, to the 
SGSN. The PDP Address Is included If the GGSN allo- 
cated a PDP address. Reordering Required Indicates 
whether the SGSN shall reorder N-PDUs before deliv- 
ering the N-PDUs to the MS. PDP Configuration Options 
contain optional PDP parameters that the GGSN may 
transferto the MS. These optional PDP parameters may 
be requested by the MS In the Activate PDP Context 
Request message, or may be sent unsolicited by the 
GGSN. PDP Configuration Options Is sent transparently 
through the SGSisi: The Create PDP Context messages 
■LTe sent over the GPRS backbone network. 
[0036] Figure 2 shows the existing QoS Profile Infor- 
mation Element It Is proposed that an additional field 
called MGTP QoS class (1 byte) is added. The SGSN 
and GGSN will make use of the Infomriatlon stored In 
this field to mark the G.PDUs with appropriate QoS 
classes. 

[0037] Note also that the QoS Reiquest, QoS Negoti- 
ated may contain two QoS Profile elements: ohe for up- 
link, one for downlink since It is likely that the traffto on 
the uplink and downlink Is asymmetric with different QoS 



requirements. 
Multi-Service OTP 

s [0038] A Multi-Service GTP (MGTP) Is derived from 
the standard GPRS GTP concept. A MGTP is defined 
both for the Gn interface, i.e: the interface between the 
GSNs (SGSN and GGSN) within a public land mobile 
network (PLMN), and the Gp interface between GSN's 

10 in different PLMNs. A MGTP tunnel is set up for use of 
a multimedia session between an MS across the GPRS 
network to the GGSN. A MGTP allows multiprotocol 
packets that bear different QoS requirements to be tun- 
nelled through the GPRS backbone between GPRS 
Support Nodes (GSNs). 

[0039] An MGTP Includes both the signalling and data 
transfer procedures. In the signalling plane, GTP spec- 
ifies a muiti-servfee tunnel control and management pro- 
tocol that allows the SGSN to provide a multimedia ac- 
cess for an MS to a GPRS networic. Signalling is used 
to create modify and delete the multi-service tunnels. 
[0040] In the transmission pleme, an MGTP uses a 
multi-sen^ice tunnel to provide a sen^ice for canying 
multimedia data packets. Two packets belonging to two 
different flows of the same QoS Class will have the same 
TID and thus will be experiencing the same tunnelling 
behaviour betweeh the SGSN and the GGSN. Only 
those packets bearing different QoS Classes will be for- 
warded in different ways through the tunnel across the 
GPRS GSNs according the specifications correspond- 
ing to their Individual QoS Classes. The exact fonvard- 
ing behaviour is decided through Multl-Servtee Group-" 
ihg which maps a QoS Class as Indicated In the TID to 
a specific Intemet protocol (IP) layer packet forwarding 
behaviour, such as the differentiated service code points 
(DSCPs) corresponding to pre-defined per hop behav- 
iours (PHB's), assured fonwardlng(AF), expedited for- 
warding (EF) or default fonvarding (DF) in DlfTSen/. 
[0041] The MGTP tunnel set-up, modification and de- 
letion procedures are similar to the standard specifica- 
tions of GPRS GTP, except that the TID for the G-PDU 
(GTP PDU) carries the QoS class that the current flow 
has been categorised into through the Multi-Servtee 
Grouping procedure. G.PDUs with the same TID (the 
same QbS Class) are multiplexed over the same type 
of NSAPIs that provides a specific f onvarding treatment 
to the G_PDUs. The IP packets that encapsulate a 
G_PDU bear some appropriate Infomiatlpn in its header 
(e.g. the DS filed) which decide its fonvarding behaviour 
across the GSN's. The IP packet forwarding Infonmalion 
Is mapped from the QoS Class included In the TID 
through the Multi-Service Grouping procedure. 
[0042] In the signalling plane, the Create MPDP Con- 
text Request/Response messages, the Update MPDP 
Context Request/Response messages and the Delete 
MPDP Context Request/Response messages contain a 
set of Per-Class QoS Profiles and a set of Row Label 
Data. The Per-Class QoS Profiles indicate the servtee' 
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classes and the tunnelling treatment of G^PDUs while 
the Row Label Data cany the specific QoS Class a 
G_PDU belongs to and are mapped to a specific packet 
forwarding treatment at the IP Layer through the Mum- 
Service Grouping. 

[0043] The concept of a MGTP tunnel extends the 
standard GPRS GTP tunnel In that a MGTP tunnel rep- 
resents an aggregate of flows belonging to different QoS 
Classes. The tunnelling behaviour and the underlying 
IP packet fonivarding treatment of each G.PDU is de- 
cided by the QoS Class It belongs to. The QoS Class is 
contained In the TID canied In the header of G_PDU. 
[0044] Once a MPD P Context is activated and the cor- 
responding MGTP tunnel Is set up, a G_PDU is assem- 
bled by encapsulating the PDU from the upper layer and 
attaching a GTP header with the TID specifically indi- 
cating the QoS Class which the G_PDU belongs to. Cor- 
responding to theTID, an appropriate NSAPl Is selected 
though which the G_PDU is dispatched down to the low- 
er layer, e.g. the IP layer where an appropriate fonvard- 
ing behaviour is selected for the IP packet canylng the 
G_PDU. 

[0045] Figure 3 illustrates an example of how the 
G_PDUs of different QoS classes are tunnelled through 
the I^GTP tunnel. G_PDUs with different QoS classes 
will have different TIDs. Each NSAPl (and the con-e- 
spondlng Flow Label) represents a particular I P fonvard- 
Ing treatment at the IP layer conrespondlng to a QoS 
Class of G_PDUs. For example, If the IP layer uses Dif- 
ferentiated Services for QoS provisioning, an IP packet 
that Is used to encapsulate a G^PDU packet has its 
DSCP (Differentiated Services Code Points) marked ac- 
cording to the mapping between the QoS Class of the 
G_PDU and DSCP, and then dispatqhed through the 
NSAP that represents a Per-Hop Behaviour con-e- 
sponding to the DSCR 

Multi-Service Grouping Functions 

[0046] Multi-Service Grouping function is a temn used 
herein to mean classifying a traffic flow Into an appro- 
priate QoS Class, quantifying the corresponding param- 
eters and mapping the QoS Classes between two adja- 
cent functional layers such as the GTP/UDP layer and 
the IP layer. Multi-Service Grouping functions generally 
include the following procedures. 

Flow Classification: 

[0047] A media component or flow In a multimedia 
session is classified into a specific QoS Class with the 
associated qualitative/quantitative parameters. 

QoS Partitioning: 

[0048] The allocation of QoS budget con-esponding 
the selected QoS Class over each network elements 
(MS, RAN/ERAN. SGSN/GGSNs) 



QoS Mapping: 

[0049] The QoS Class is mapped to specific service 
class/priority levels at the network/MAC layer with the 

5 conrespondlng parameters translated. 

[0050] Multi-Service Grouping function may also In- 
clude traffic monitoring and policing to maintain the traf- 
fic pattern within the pre-defined (or negotiated) 
QoS_Profile. For example, the bit rate of an incoming 

10 traffic flow must be limited within Its registered peak rate. 
Any packet found to have exccecied this ;.v:^=iCifiCiiiion in 
the QoS^Profile will be either shaped (queued for a 
longer delay) or dropped. 

15 Service Differentiation at MSAJE 

[0051] The Sen/ice Differentiation functionality can be 
located at the teminal equipment (TE) from which an 
MPDP Context Activation Request is Initiated in re- 
20 sponse to the set-up request of a multimedia session. 
During the session set-up, tiie MSAJE (MT) needs (TR 
23.907) to perform the Multi-Service Grouping function 
to 

Classify Its media components into the ccrre- 

25 spending QoS Class. 

[0052] Decldethe qualitative and/or quantitative Qo3 
budget for each selected QoS Class 
[0053] Map the QoS Classes and its parameters to 
the lower layer (LLC/MAC or RLC/MAC) QoS Classes 

30 and the corresponding parameters. 

[0054] (optional) The MT may also need to monitor 
and police the traffic before It is injected into the network. 
[0055] In addition to the Multl-Sen^lce Grouping, the 
Servtoe Differentiation at the MS/UE also includes the 

35 control operations for MPDP Context Activation/MGTP 
Set-up as described above. 

[0056] During the data transfer, the MS/UE (a^FT) 
marks each packet with its corresponding QoS Qiasa 
and selects the matching NSAPl with the appropriate 
40 radio access bearer to dispatch the packet. 

Service Differentiation In GSN Nodes (SGSN/GGSN) 

[0057] For Sen/ice Differentiation at SGSfM/GGSN, 
45 Multi-Service Grouping needs to be performed before 
and during data transfer between SGSN and GGSN. A 
MS/UE initiated multimedia service request with the as- 
sociated QoS Classes needs to be authorised according 
to the sul3scribed QoS_Profiles. A multimedia service 
50 request from an authorised user will also nsed to go 
through the admission control perfomned by the Murci- 
Service Grouping at the SGSN and GGSN. 
[0058] An authorised MS/UE that has been success- 
fully admitted for access to the networtc will be assigned 
55 the necessary network resources e.g. memory, central 
processing unit (CPU), buffers for storing MPDP Con- 
text, transporting bearer data in the MGTP tunnel at the 
SGSN/GGSN. 
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[0059] For the uplink traffic, a packet that arrives at 
the SGSN will be encapsulated by a GTP tunnel header 
with appropriate Flow Label and TID marking. The TID 
' '.?!+NSAPI) is used to select the corresponding tun- 
..o '^c.vicur Finally the G_PDU is dispatched through 
the NSAPI and transfen'ed through the MGTP tunnel to 
the GGSN. The SGSN may also need to perfonn Multi- 
Service Grouping function (monltoring/poiicing/shap- 
ing) during the data transfer so as to guarantee that the 
traffic behaviour confomns to the negotiated 
QoS_Profile. 

[0060] For the downlink traffic, a packet that arrives 
at the GGSN from the external network will go through 
the similar processing as demonstrated In Figure 2. The 
Multi-Service Grouping (monltoring/pollcing/shaping) Is 
perfomned by the GGSN before a G_PDU is dispatched 
■ thft lower network layer. 

Service DlfferenilaUon in ERAN 

[0061] Service differentiation at the ERAN (EGPRS 
Radio Access Network) Is to categorise the user data 
PDUs according to their specific QoS Classes and put 
them in the corresponding queues at the LLC layer and 
finally selects the right radio channels to send the MAC 
frames carrying the LLC PDUs from different LLC 
queues. 

[0062] Figure 4 illustrates how different QoS classes 
can be supported at various layers at the MT. User data 
" '"'-^sts, e.g. point to point protocol (PPP) frames, are 
j.saslfied and marked with different QoS classes 
through the Multi-Service Grouping process.. Then they 
are packaged Into LLC PDUs, each of which bears a 
LLCtypethat Is mappedfromthe QoS Class of the pack- 
ets and are placed Into different queues that feature dif- 
ferent media access priorities Vendor specific schedul- 
ing algorithms can be used to schedule dispatching of 
LLC PDUs in the different queues for the uplink trans- 
missions. During the media access control, MT sends a 
packet resource request message specifying the LLC 
type. Upon hearing a radio uplink assignment message, 
I^T can then fragment the LLC PDUs Into appropriate 
C/MAC blocks and transmit them via the appropriate 
:;nyslcai channels shown as Ml and M2 in Figure 3 . 
[0063] Figure 5 illustrates the procedure taken by the 
BSS to ensure that the uplink base station system 
GPRS protocol (BSSGP) PDUs bearing different QoS 
can be achieved. The BSS reassembles LLC frames 
and put them Into different queues based on the LLC 
type. Then, again vendor specific scheduling algorithms 
can be used to schedule the transmission of these LLC 
frames to the SGSN. These LLC frames are encapsu- 
lated and sent as BSSGP PDU packets. 
[0064] Similariy Figure 6 illustrates the procedure tak- 
^tt by the BSS to ensure the differentiation at the LLC/ 
V A layers for BSSGP PDUs with different QoS Class- 
es tor the downlink traffic. BSSGP PDUs received by 
the BSS are decapsulated to reveal the LLC frame types 



and put in separate queues. Vendor specific downlink 
scheduling algorithms are used to transmit these LLC 
frames to the MAC Segmentation and Reassembly 
(SAR) sublayer where these LLC frames will be frag- 

s mented Into different RLC/MAC blocks to be transmitted 
over different physical channels. 
[0065] One of the possible way of enhancing the LLC 
headers to include QoS infomiatlon is to add an extra 
byte to the control field (at the top) to Indicate different 

10 LLC type as shown In Figure 7. 



Claims 

^5 1. A radio communication network In which data flows 
between nodes In packets, In which each flow is as- 
signed to one of a plurality of types of network serv- 
ice access points, different types of networic 8ervk:e 
access points providing different classes of quality 

20 of service. 

2. A network as claimed In claim 1 , in which each pack- 
et in a flow has a header containing a network serv- 
ice access point indicator identifying the type of net- 

25 work service access point required to provide a 
quality of service allocated to the flow. 

3. A network as claimed in claim 2, in which a plurality 
of flows relating to a single mobile station, which 

30 flows are allocated the same or different quality of 
service classes, are assigned to a single multi-serv- 
ice tunnel defined In the packet headers by the com- 
bination of an address of the mobile and the network 
service access point Indicator. 

35 
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